延續上一篇的主題，來討論兩個我們尚未納入運用的功能：analysis & exposure。

Analysis

analyses:
  - name: <analysis_name> # required
    description: <markdown_string>
    docs:
      show: true | false
      node_color: <color_id> # Use name (such as node_color: purple) or hex code with quotes (such as node_color: "#cd7f32")
    config:
      tags: <string> | [<string>]
    columns:
      - name: <column_name>
        description: <markdown_string>
      - name: ... # declare properties of additional columns

  - name: ... # declare properties of additional analyses

從一開始初始化 dbt repo 時，就會一直看到一個名為 analysis（analyses） 的 folder 一直很礙眼（誤）

一直沒有認真研究它的功能，這次在談 dbt 與下游的數據連貫性時，發現它其實是一個蠻有相關的功能，因此來跟大家介紹一下。

Any .sql files found in the analyses/ directory of a dbt project will be compiled, but not executed. 

這是針對這個資料夾的操作說明。你可能會想說 compile 成 SQL code 之後不執行是何必呢？

他的目的與名稱相同，是為了做分析使用。

很多時候，我們會突然有一些想法（或是上頭有一些想法），需要寫一些 SQL code 來查詢資料，看看能否印證這些想法的可能性，這種情境應該屢見不鮮。

這時候我們最常做的事情就是直接在 BigQuery 中花個幾分鐘速速寫一段 SQL code，把結果秀出來，如果沒有其他想法的話，可能就止步於此，分頁關閉後就不復存在。

而如果你（老闆）有一些新的想法，這件事情可能就會繼續往下討論，也會繼續把 SQL code 寫得越來越長，最後在某一個節點時，突然想通了、或是發現需要更多的資源才能繼續進行。

這時候如果覺得 SQL code 已經寫了好長一段，之後搞不好有人又來問、還會用到，就會把 code 在 BigQuery 找個地方存起來。但都已經用 dbt 了，其實 BigQuery 的倉儲不太乾淨，很有可能有其他更多人一起使用，你可能之後就找不到他儲存的位置，甚至其他人不知道你的 SQL code 有何用處，直接被丟進垃圾桶，下次要用時又要再重寫一次。

就我的理解，Analysis 就是為了儲存這樣的內容，你進行了一些有意思的分析，想要保留起來，卻又不需要讓他自動化定期更新，就可以把這樣一個有主題性的分析內容，儲存在 Analysis 中，未來想使用時可以直接執行這段 code、或是複製到任何可運行 SQL code 的平台做使用。

他不只可以記錄分析內容，你也可以用所有 dbt 中定義的 macro 等工具，並且也支援 lineage 的功能，若有任何修正改動到分析內容的上游，可以在 dbt 的 lineage graph 就知道，絕對是資料治理中避免資料孤島的一大福音。

而跟其他資料模型一樣，可以在 yaml file 中做更多的補充敘述，像是把跟老闆的討論串連結貼到 description 中，對後人來說絕對有很大的幫助。

Exposures

exposures:

  - name: weekly_jaffle_metrics
    label: Jaffles by the Week              # optional
    type: dashboard                         # required
    maturity: high                          # optional
    url: https://bi.tool/dashboards/1       # optional
    description: >                          # optional
      Did someone say "exponential growth"?

    depends_on:                             # expected
      - ref('fct_orders')
      - ref('dim_customers')
      - source('gsheets', 'goals')
      - metric('count_orders')

    owner:
      name: Callum McData
      email: data@jaffleshop.com

而另外則是統整這些分析或其他內容的整合性功能 —— exposures。

這邊就是單純使用 yaml file 來定義，就我理解，他就是與外部工具串接的管理處。

譬如上一章中我提到我們使用 Metabase 作為我們的視覺化工具，而 exposure 就可以紀錄 Metabase 的連結與資訊，並且透過其中的 depends_on 來紀錄 lineage，確保 dbt 與下游服務不脫鉤。

不過這就很需要人工去維護，每次處理 Metabase 後，就要同步於此進行更新，過於重工的步驟有點讓人望之卻步。

我是覺得針對核心的指標系統，有很高頻的使用率的下游應用等，可以透過 exposures 來進行管理，像它有提到它不只可以紀錄 analysis，也可以紀錄其他的 notebooks, ml, application 等等，針對這種不能斷線、且受到更嚴謹管理的服務，我覺得就蠻適合透過這種方式管理。

至於業務端偶爾看一次的報表，我覺得就可以在出問題時人工報修就好了（喂喂喂ＸＤ）

當然人夠多我也想修，但咱們的 DA 大都是 DE 兼任處理的，幾百張儀表板沒辦法這麼精細啊…

以上！介紹兩個可以增進下游數據串接品質的功能。